System for communication of health care data

ABSTRACT

An apparatus for communicating health care data from a sender to a receiver is provided. The apparatus has a first computer system ( 10 ), a second computer system, and a rules engine. The first, computer system ( 10 ) has health care data stored therein. The second computer system is in operable communication with, and is configured to extract the health care data from the first computer system ( 10 ). The rules engine normalizes the extracted health care data to a predefined format. The rules engine defines a plurality of health care data fields in the predefined format, as well as a plurality of relationships between fields of normalized data.

RELATED APPLICATION

[0001] The present application is related to and claims priority to U.S.Provisional Patent Application Serial No. 60/239,860, filed Oct. 11,2000, entitled “Apparatus and Method for Establishing Connectivity.” Tothe extent not included below, the subject matter disclosed in thisapplication is hereby expressly incorporated into the presentapplication.

FIELD OF THE INVENTION

[0002] The present invention relates generally to a computerized systemthat establishes connectivity between interested parties in the healthcare industry for the administration of health care services. Moreparticularly, the present invention relates to a system for thenormalization of health care data of various formats and exchanging thedata in normalized form between insurers and participants, such asproviders, patients, and employers.

BACKGROUND AND SUMMARY

[0003] Health care can be defined as an information industry; most ofthe time and money spent in procuring and delivering health care isspent creating, retrieving, or using information. Expenditures on healthcare information technology support, for example, have increased fromabout one billion dollars in 1990 to a projected $20 billion in 2000.Yet, even with these investments, it is believed that almost half of allcurrent health care expenditures continue to be for non-patient careactivities; a major share of which is for non-automated informationsupport.

[0004] Resources having to be directed to non-patient care activitieshave been endemic in the health care industry since the 1960's. Duringthe 1990's, however, with the demise of Medicare Cost Reimbursement andthe rise of managed care, there has been a major shift in attitude andfocus among both physicians and patients. New rules now govern thedelivery of medical care and the payment for such care. Whether viapreferred provider arrangements, capitation arrangements of endlessvariety, case management, or “best practice” enforcement, determiningwhat care is allowed, what will be paid by whom, and making sure thatthe appropriate information is submitted to ensure that the processworks are now consuming a major share of both time and financialresources of insurers, providers, and patients.

[0005] Health care participants, like providers and employers, regularlydeal with a number of health care plans from various health insurers.These participants, however, can only obtain information from theinsurance companies in limited ways, often making the acquisition ofsuch information quite burdensome. Participants usually only have thetelephone, fax, or letter available as a means of communication with theinsurers.

[0006] Particularly vexing is the timely availability of informationfrom insurers regarding financial transactions, such as eligibility,claims, and benefits, and basic patient-related information, such asmedical tests and prescriptions. For example, a provider may seekinformation from an insurer via a submission form or telephone call tothat insurer. In many cases, however, such information is sought orreceived after the care has been delivered and the patient has left theprovider's office. This may result in the delivery of services that arenot authorized or covered by the patient's insurer, or may result inother consequences that might impact the type or cost of the servicesprovided.

[0007] Another reason for these difficulties is the recent expansion ofthe “payor” community. At one time, payors consisted of the government(both federal and state) and large insurance companies. Now, a complexarray of self-insured plans, IDN's, IPA's, and PPO's; undertaking fullor partial capitation, insurance carve-outs, and the like have radicallyincreased the number of users of, and the need for, current informationregarding insureds. Most of these entities, both small and large, dospend considerable sums on information systems. Yet, because of theextent of manual processing that exists despite these systems; costs perclaim remain substantial.

[0008] In addition, payors incur the wrath of their providers andpatients by designing complex rules that are difficult or perceived asimpossible to administer or follow. Though contrary to this perception,payors do have an interest in providing timely information to providers,patients, employers, and other participants. Still, a significantpercentage of a provider's claims are rejected often because they do notcomply with all of the rules. These claims require resubmission,telephone calls, and other expensive manual interventions. The dollarcosts for this current processing scheme are high. In fact, an entireclearinghouse industry has been developed to provide eligibility (butnot benefits) verification services to providers for a fee. Many of therequested verifications, however, cannot be performed at all by suchclearinghouses, and those that are performed are often unacceptablycumbersome and, thus, too expensive.

[0009] Referral authorizations are often even more complex than claimsand such authorization services are generally not available viatraditional clearinghouses. Each time a provider writes a prescription,for example, it is written against a formulary specific to thatpatient's health care plan established by their insurer. Because thereare so many formularies, drug prescriptions, too, are often rejected forpayment, causing additional work for both the provider and the patient.Similarly, medical tests must be sent to laboratories contracted tosupport a particular plan, and are reimbursed only when matching complexmedical necessity rules.

[0010] Many providers do have practice management systems that trackencounters and manages billing. None of these systems, however, have thesophistication to accomplish the task of providing all of theinformation from all the various health insurers in such a cogent formthat can be useful to the provider.

[0011] Not only providers, but patients, too, spend a majority of theirtime interacting with the health care system engaged in non-health careactivities. This “wasted” time is virtually all related to schedulingappropriate interventions, to waiting for information or services, or toobtaining authorization, reimbursement, or other information for desiredor required health care.

[0012] The internet has emerged as a major source of health careinformation for the public. A substantial portion of internet users useit for health care information or management. Specifically, patientssearch the internet for medical information and answers related to theirarea of concern. In fact, it is becoming common for a patient to enter aphysician's office armed with printouts and long lists of questions andrecommendations from web pages on the internet.

[0013] Unfortunately, even with the connectivity the internet provides,information exchange between insurers and patients is lacking. Most ofthe information available to patients from their insurer is on anautomated basis from databases related to either general health careliterature or to specific normality support groups. A critical aspect ofthe patient's health care program, however, is not only knowledge of thenormality or support groups, but also what their insurer's health careplan provides as treatment options for that normality, eligibilityinformation, referral authorization, claim submission and payment,testing, and medications. As discussed, these functionalities are toocomplicated for the current system to handle in an automatedenvironment. Personally-referenced information linked to an individualpatient's provider and health care plan is generally unavailable,because that data exists in several databases often each in a different,incompatible format, requiring human intervention to extract and processthe data. The patient's current solution is, thus, an endless number oftelephone calls at a high cost in dollars, time, and frustration.

[0014] A reason for such incompatibility is that each database servedthe individual needs of those using the data before such a time whenconnectivity between databases was a consideration. The consequence ofhaving different databases of different formats is that it is notpossible to provide a central repository of homogenized data readable byany variety of computers. It is this incompatibility that prevents widespread connectivity between insurers and participants.

[0015] Transliterating and interfacing programs are known in the art.Programs that take data in one format can be translated and read by acomputer of a different format. Such transliterating, however, onlyshifts data from a field of an incompatible format to a target field ofa new format. It cannot determine whether the data of the incompatibleformat is being transferred to the correct target field. Normalizationor remodeling of the data not only transfers the data, but alsodetermines the meaning of the data and puts that data in the correctfield.

[0016] It would, therefore, be beneficial to provide a system with whichinsurers may communicate with providers, patients, etc., to provideinformation about a particular health care plan either before, orcontemporaneously with, the patient's visit to the provider, regardlessthe lack of compatibility of the databases. It would be furtherbeneficial if this system of communication spanned a variety of insurersso the provider, for example, may communicate with any plan in which thepatient participates. It would also be beneficial for providers to havean automated system of determining eligibility and benefits, receivingauthorizations and pre-certifications, submitting claims, obtainingreimbursements, and adjudicating claim problems through thenormalization of data of the incompatible databases.

[0017] Accordingly, an illustrative embodiment of the present disclosureprovides an apparatus for communicating health care data from a senderto a receiver. The apparatus comprises a first computer system, a secondcomputer system, and a rules engine. The first computer system havinghealth care data stored therein. The second computer system is inoperable communication with, and is configured to extract the healthcare data from the first computer system. The rules engine normalizesthe extracted health care data to a predefined format. The rules enginedefines a plurality of health care data fields in the predefined format,as well as a plurality of relationships between fields of normalizeddata.

[0018] Further embodiments may include the first computer being aplurality of computers each having portions of the health care datastored thereon. The apparatus may also comprise a third computer system,in operable communication with, and configured to receive the normalizeddata from, the second computer system. The rules engine may determinewhether the third computer is authorized to receive the health caredata.

[0019] Another illustrative embodiment provides a method forcommunicating health care data from one computer system to another. Themethod comprises the steps of storing health care data in a firstcomputer system; extracting health care data from the first computersystem and communicating the extracted data to a second computer system;normalizing the extracted data to a predefined format in accordance witha rules engine that defines a plurality of health care data fields inthe predefined format and a plurality of relationships between fields ofnormalized data; and communicating the normalized data to a thirdcomputer system.

[0020] Further embodiments of the illustrative method may include thefirst computer system comprising a plurality of computers, wherein thestoring step includes storing health care data in more than one of saidcomputers. Also, the third computer system comprises a plurality ofcomputers. The health care data exists across a plurality of databasessuch that each of the plurality of databases are in operablecommunication with the second computer system.

[0021] Another illustrative embodiment provides a system of exchanginghealth care data between a sender and a receiver. The system comprises asender computer, an intermediary computer, a rules engine and a receivercomputer. The sender computer stores the health care data. Theintermediary computer is in operable communication with the sendercomputer and is configured to extract the health care data. Theextracted data is normalized to a predefined format, creating normalizeddata pursuant to a rules engine. The rules engine defines each field ofthe health care data and converts each field to a corresponding field inthe predefined format. The rules engine also defines how the normalizeddata should relate to each other pursuant to predetermined instructions.The receiver computer is in operable communication with the intermediarycomputer. The receiver computer receives the normalized data subjectedto the second rules engine.

[0022] Further embodiments may include the sender computer being aplurality of computers each having portions of the health care datastored thereon. The rules engine may determine whether the receivercomputer is authorized to receive the health care data. When thereceiver is a health care provider, the normalized data exchangedbetween the sender and receiver may be chosen from a group comprisingeligibility/benefit display, member roster, claim submission, providerlookup, formulary lookup, diagnosis code lookup, procedure code lookup,access health plan information online, communicate with a health planon-line, communicate with patients on-line, patient-centric view of dataacross several health plans, order generation and tracking, resultsreview and release, result printing, prescription writing, medicationprofile for each patient, access to patient's personal health recordbased on patient approval, personalized medical and health care contentintegration, both context-specific and on demand, e-commerceintegration: office, medical and health-related product awareness andbuying capabilities, email, practice management system subscription,support disease management, and physician credentialing subscription.When the receiver is an employer, the normalized data exchanged betweenthe sender and receiver is chosen from a group comprising groupeligibility, group enrollment, enrollment changes, formulary lookup,e-commerce integration, access from health plan web site or directaccess via URL, personalized content integration, both context-specificand on demand, e-commerce integration and health care-related productawareness and buying capabilities.

[0023] When the receiver is a patient, the normalized data exchangedbetween the sender and receiver is chosen from a group comprisingidentification card requests, address changes, provider directoryinquiries, personalized health information based on an interest profile,diagnosis information, relevant articles and patient educationmaterials, communications from health care providers and health careplans, lab and radiology results, scheduled appointments with a healthcare provider, prescription refills, personal health records,eligibility/benefit information, claim information, referral andauthorization information and status, provider lookup, family history,medication profile and formulary lookup.

[0024] Another illustrative embodiment of the present invention providesa system of normalizing health care data for transfer between an insurerand a participant. The system comprises an insurer system, anintermediary system, and a participant system. The insurer system isconfigured to maintain at least one database comprising the health caredata. The intermediary system is operatively connected to the insurersystem and to the database, configured to extract the health care datafrom the database of the insurer system, and store the health care datain a staging database as extracted data. The extracted data isnormalized to a predefined format, creating normalized data pursuant toa rules engine that defines each field of the extracted data in thepredefined format. The rules engine also defines how the normalized datarelates to each other pursuant to predetermined instructions. Theparticipant system is in operable communication with the intermediarysystem, and is configured to receive the normalized data subject to therules engine.

[0025] Further embodiments of the illustrative system may include the atleast one database being a plurality of databases, such that theintermediary system is operatively connected to the plurality ofdatabases. In addition, the participant system may transmit a requestthat is sent to the intermediary system that determines which healthcare data is to be extracted and normalized in order to respond to therequest. The participant system may also transmit the request, and theintermediary system may transmit the normalized data over the internet.The rules engine may define the relationships among the normalized datapursuant to predetermined instructions to determine a response to therequest. The intermediary system may also comprise an error data systemthat removes extracted data identified as invalid when the extracteddata is normalized. The extracted data identified as invalid is thencorrected, reintroduced, and is normalized. The intermediary system mayfurther comprise an audit database to track the activity of theintermediary system.

[0026] Another illustrative embodiment of the present invention providesa system of health care management of medical testing administrationbetween an insurer, a medical laboratory, and at least one health careparticipant. The system comprises a participant computer, an insurerprocessing system, a rules database, and a laboratory computer. Amedical test request is made at the participant computer pursuant to afirst predetermined format. The insurer processing system is operativelycoupled to the participant's computer, and is through which the medicalrequest is transferred. The processing system is operatively coupled tothe rules database to approve the medical test request pursuant topredetermined criteria. The laboratory computer is operatively coupledto the processing system and receives the medical test request ifapproved by the rules engine. Results of the medical test aretransmitted from the laboratory computer to the processing system. Theresults are further transmitted to an insurer computer that isoperatively coupled to the laboratory computer and to participant'scomputer.

[0027] Further embodiments of the illustrative system may include theprocessing system converting medical test to a second predeterminedformat readable by a database stored on the insurer computer. Inaddition, at least one health care participant may be chosen from agroup comprising from a health care provider, an employer, and apatient. Furthermore, the medical test request and the results of themedical test may be transmitted through the internet.

[0028] Additional features and advantages of the system will becomeapparent to those skilled in the art upon consideration of the followingdetailed descriptions exemplifying the best mode of carrying out thesystem as presently perceived.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The illustrative system will be described hereinafter withreference to the attached drawings which are given as non-limitingexamples only, in which:

[0030]FIG. 1 is a diagrammatic view of a system for normalization ofhealth care data and the exchange of same between several health careinsurers and various health care participants;

[0031]FIG. 2 is a diagrammatic view of the data processing system forthe system of normalization shown in FIG. 1;

[0032]FIG. 3 is a diagrammatic view of the data extraction and businessobject sub-systems for the system of normalization shown in FIG. 1; and

[0033]FIG. 4 is a diagrammatic view of a system of health caremanagement for-medical testing between health care insurers andparticipants.

[0034] Corresponding reference characters indicate corresponding partsthroughout the several views. The exemplification set out hereinillustrates an embodiment of the invention, and such exemplification isnot to be construed as limiting the scope of the invention in anymanner.

DETAILED DESCRIPTION OF THE DRAWINGS

[0035] An illustrative embodiment of the invention, such as that shownin FIG. 1, comprises a system 2 which includes a plurality of databasesets 4, 6, 8 offered by a variety of insurers 11. It is appreciated thateach health care database set 4, 6, 8 represents an insurer's databaseprocessing system or series of processing systems and databases. Forexample, database sets 4, 6 or 8 may each represent a conventionalcomputer system, a server, a local area network (LAN), a legacy, orother computer system storing one or more databases. It is contemplatedthat to transmit data, either the system as it exists is capable ofdoing so, or a system is added to either database sets 4, 6, or 8 toperform this function. It is further contemplated that each of database*sets 4, 6, 8 may represent a single database or a plurality ofdatabases, each of which may be of any variety of database formats orlanguages.

[0036] For the purposes of this application, it is contemplated thatreference to the term “insurer,” as used herein for insurers 11, is forillustrative purposes only. Such a term includes health insurancecompanies, but also includes health maintenance organizations,self-insured entities, disease management organizations, capitatedhealth care providers, Medicare agencies, as well as any otherorganization that might store or manage health care data. The term“insurer” is not to be construed as being limited in scope to onlyhealth insurance companies or other “payors.”

[0037] Conventionally, health care data is stored on an insurers'computer or series of computers in several databases, each of whichoften being in a unique format, with each database format beingincompatible with other database formats. For example, one insurer mayhave their health care data stored in one format, and a second insurermay have their health care-related data stored in a second format thatis not compatible with the one format. Additionally, and moreproblematic is that, even within the same insurer's 11 system,eligibility data, for example, may exist in a database of one particularformat, developed to suit the needs of its users at the time, whereas,the claims data, for example, may be stored in another database in aformat that suits the needs of those users, but with its format beingincompatible with the format of the eligibility data. In either example,it is contemplated that in the present invention, health care data ofany format is normalized into a common format, and distributed through acommon network, like internet 12, to a health care participant 13, whouses the normalized data to conduct health care-related transactions andtasks. It is further contemplated, and to be discussed further herein,that various levels of access and security can be provided to assurethat those participants 13 accessing the normalized data are authorizedto access only that data predetermined as necessary and appropriate fortheir particular use or need.

[0038] As FIG. 1 shows, data from each database set 4, 6, 8 can betransmitted to a data processing system 10 that normalizes the data intoa format readable by particular health care participants 13. Morespecifically, the data is transmitted over the internet 12, which isoperatively connected to and read by participants' 13 computer(s) orterminal(s). Such participants 13 illustratively include providers 14,employers 16, and patients 18, or any combination thereof. It iscontemplated that participants 13 can further include any otherinterested party that can request data or information from an insurer,including other insurers and disease management organizations, forexample.

[0039] It is contemplated that the transmission of data from databasesets 4, 6, or 8 is initiated by any of the participants 13 submitting arequest 22 through a computer or computers. Request 22 is transmittedthrough the internet 12 to data processing system 10 which retrieves theappropriate data from the appropriate database set or sets of either 4,6, or 8. That data is normalized to a common format, at which point aresponse 24 to the request 22 is made. For example, a health careprovider 14 may place a request 22 on behalf of an insured to authorizepayment for a medical procedure. In this example, it is presumed thatthe data required to formulate a response 24 exists collectively oneligibility, benefits, and claims databases that illustratively exist ondatabase set 4. Data processing system 10, in order to prepare aresponse 24, determines and extracts which data is necessary from thedatabases. System 10 then normalizes the data into a homogenous format,and then determines what the nature of the response should be. In thisexample, response 24 should be to either authorize or deny payment forthe medical procedure. System 10 uses the normalized data to determinethe response, which is then transmitted to provider 14, thus, completingthe transaction. It is contemplated that system 2 may comprise anynumber of insurers 11 or participants 13. Specifically, data processingsystem 10, as will be discussed further herein, is able to connect andmanage transactions between a single or plurality of participants 13with any insurer or plurality of insurers 11.

[0040] It is further contemplated that system 2 will provide health careparticipants 13 with a variety of health care transaction optionsreferred to generally in the form of requests 22 and responses 24between participants 13 and insurers 11. Examples of transactionsavailable to health care providers 14 are: eligibility/benefit display,member roster, claim submission, provider lookup, formulary lookup,diagnosis code lookup, procedure code lookup, access health planinformation online, communicate with a health plan on-line, communicatewith patients on-line, patient-centric view of data across severalhealth plans, order generation and tracking, results review and release,result printing, prescription writing, medication profile for eachpatient, access to patient's personal health record based on patientapproval, personalized medical and health care content integration, bothcontext-specific and on demand, e-commerce integration: office, medicaland health-related product awareness and buying capabilities, email,practice management system subscription, support disease management, andphysician credentialing subscription.

[0041] As further example, the following are specific records and fieldsfor health care transactions between providers 14 and insurers 11 thatutilize normalized data:

[0042] Record: Summary

[0043] Fields:

[0044] Activity for (date)

[0045] Referrals

[0046] Claims

[0047] Test Results

[0048] Members Update

[0049] State for Americas Health

[0050] Benefit Records

[0051] Claim Records

[0052] Patient Records

[0053] Provider Records

[0054] New Just For You

[0055] Record: Eligibility

[0056] Fields:

[0057] Today's Patients

[0058] Patient Search

[0059] Sex

[0060] Coordination of benefits

[0061] Medicare data

[0062] Add to patient list

[0063] Name From

[0064] Date

[0065] To Date

[0066] Birth date

[0067] Member ID

[0068] Relation

[0069] PCP

[0070] Address

[0071] City

[0072] State

[0073] zip

[0074] Current Benefit

[0075] Group

[0076] Carrier

[0077] Benefit Plan

[0078] Record: Claim Status

[0079] Fields:

[0080] Patient Name

[0081] From Date

[0082] To Date

[0083] Claims

[0084] Claim Number

[0085] Status

[0086] Provider Name

[0087] Patient Name

[0088] Member Number

[0089] Billed Amount

[0090] Patient Responsibility

[0091] Paid Amount

[0092] Date of Service

[0093] Record: Claim Detail

[0094] Fields:

[0095] Member

[0096] Provider

[0097] Diagnosis

[0098] Description

[0099] Line number

[0100] DOS

[0101] CPT

[0102] Description

[0103] Modifier

[0104] Location

[0105] Units

[0106] Status

[0107] Billed

[0108] Allowed

[0109] Copay

[0110] Coinsurance

[0111] Deductible

[0112] Paid

[0113] Totals

[0114] Record: Explanation of Payments

[0115] Fields:

[0116] Line Number

[0117] Status Description

[0118] Explanation

[0119] Check/Date

[0120] Record: Select Specialist

[0121] Fields:

[0122] Address

[0123] City, State, Zip

[0124] Handicap Access

[0125] Office Hours

[0126] Contact

[0127] Phone

[0128] Fax Phone

[0129] Phone After Hours

[0130] Sex

[0131] Birth Date

[0132] Specialty

[0133] Second Specialty

[0134] Accept Patient

[0135] Primary Care

[0136] Board Cert

[0137] Languages

[0138] Hospitals

[0139] Hospital Privileges

[0140] Networks

[0141] Record: Add Claims

[0142] Fields:

[0143] Health Insurance

[0144] Insured's ID Number

[0145] Patient Last Name

[0146] First Name

[0147] Middle Name

[0148] Patient's Address 1

[0149] Address 2

[0150] City

[0151] State

[0152] Zip

[0153] Patient's Phone

[0154] Birth date

[0155] Gender

[0156] Relationship to Insured

[0157] Marital Status

[0158] Patient Employment Status

[0159] Condition Related to Job

[0160] Con. Rel. to Auto Accident

[0161] Cond. Rel. to Other Accident

[0162] Insured's Last Name

[0163] First Name

[0164] Middle Name

[0165] Gender

[0166] Birth date

[0167] Insured's Address 1

[0168] Address 2

[0169] City

[0170] State

[0171] zip

[0172] Phone

[0173] Insured's Group or FECA Number Insured's Employer/School

[0174] Insured's Insurance Name

[0175] Referring Physician Name

[0176] Referring Physician ID

[0177] Outside lab

[0178] Outside Lab Charges

[0179] Medicaid Resub Code

[0180] Medicaid Orig.

[0181] Prior Auth. Number

[0182] Diag Codes

[0183] Item

[0184] Date From

[0185] Date To

[0186] Place

[0187] Type

[0188] Procedure

[0189] Mod1

[0190] Mod2

[0191] DX Ind.

[0192] Charges

[0193] Days/Units

[0194] Patient

[0195] Provider

[0196] From Date

[0197] To Date

[0198] Diagnosis 1

[0199] Diagnosis 2

[0200] Diagnosis 3

[0201] Diagnosis 4

[0202] Procedure Line

[0203] CPT

[0204] Description

[0205] Amount

[0206] Dx pointer

[0207] Other Errors

[0208] Total Amount

[0209] Billed

[0210] Allowed Amount

[0211] Copay Amount

[0212] Withheld Amount

[0213] Writeoff Amount

[0214] Predicted Payment

[0215] Record: Referral Status

[0216] Fields:

[0217] Referral Number

[0218] Patient (Member ID)

[0219] Valid from (months)

[0220] Referred by

[0221] Referred to

[0222] Patient List

[0223] Referred by

[0224] Referred to

[0225] Referral Number

[0226] Status

[0227] Record: Add Referrals

[0228] Fields:

[0229] Today's Patients

[0230] Patient Search

[0231] Specialists

[0232] Specialist Search

[0233] Providers

[0234] Diagnosis

[0235] Patient

[0236] Specialists

[0237] Provider

[0238] Diagnosis Start

[0239] Date

[0240] Months Valid

[0241] Visits Requested

[0242] Reason

[0243] Record: Procedure and Diagnosis Data

[0244] Fields:

[0245] Diag Number

[0246] Diagnosis Name

[0247] Procedure Name

[0248] Visits Allowed

[0249] Patient

[0250] Patient Search

[0251] Referred to

[0252] Specialist Search

[0253] Referred by Diagnosis

[0254] Start Date

[0255] Exp Date

[0256] Visits Requested

[0257] Remarks

[0258] Services Requested

[0259] Authorized Ancillary Services

[0260] Record: Diagnosis Codes

[0261] Fields:

[0262] Diagnosis Code

[0263] DX Code

[0264] Diagnosis Code Description

[0265] Record: Procedure Codes

[0266] Fields:

[0267] Procedure Codes

[0268] Procedure Code

[0269] Procedure Description

[0270] Age From

[0271] Age To

[0272] Sex

[0273] Location Code

[0274] Record: Drug Therapeutic Class Listing

[0275] Fields:

[0276] Therapeutic Class

[0277] Class Description

[0278] Count of Drugs in this Class

[0279] Record: Formulary List by Therapeutic Class

[0280] Fields:

[0281] Drug Name

[0282] Generic Name

[0283] Drug Class

[0284] Therapeutic Class

[0285] NDC

[0286] Record: Write Prescription

[0287] Fields:

[0288] Today's Patients

[0289] Patient Search

[0290] Providers

[0291] For

[0292] Medication

[0293] Dispense

[0294] Refill

[0295] Sig: Take

[0296] Sig: For

[0297] Instructions

[0298] Select Pharmacy

[0299] Record: Medication Profile

[0300] Fields:

[0301] Type

[0302] Medication

[0303] Dose

[0304] Frequency

[0305] Reason

[0306] Status

[0307] Record: Discontinued Medications

[0308] Fields:

[0309] Type

[0310] Medication

[0311] Dose

[0312] Frequency

[0313] Reason

[0314] Status

[0315] Record: Allergies

[0316] Allergen

[0317] Reaction

[0318] Date Started

[0319] Record: Medical Test Orders

[0320] Fields:

[0321] Patient ID

[0322] Patient Name

[0323] Provide ID

[0324] Provider Name

[0325] Location

[0326] Lab Name

[0327] Dx

[0328] Action

[0329] Battery

[0330] Test

[0331] ID

[0332] Type

[0333] Volume

[0334] Date

[0335] Time

[0336] Collected By

[0337] Chemistry

[0338] Hematology

[0339] Toxicology/Therapeutics

[0340] Microbiology/Virology

[0341] Immunology/Serology

[0342] Urinalysis/Fluids

[0343] Procedure

[0344] When

[0345] Priority

[0346] Specimen

[0347] Alert

[0348] Record: Results

[0349] Fields:

[0350] Status

[0351] Order number

[0352] Test Procedure

[0353] Alert

[0354] Order Date

[0355] Facility

[0356] Patient

[0357] Provider

[0358] Date/Time

[0359] Procedure

[0360] Status

[0361] Indicator

[0362] Date/Time

[0363] Performed

[0364] Specimen Number

[0365] Type

[0366] Status

[0367] Result

[0368] Value

[0369] Desired Range

[0370] Each field listed above represents data that can exist anywhereon database sets 4, 6, or 8, and be in any format or language. If anyrequest 22 is made which calls up one or more of the above records, dataprocessing system 10 searches, extracts, and normalizes the data so itappears in the correct field in the record. It is appreciated thatprovider 14 may change the data, if necessary, and transmit it backthrough internet 12 and data processing system 10 to be stored on theappropriate database set 4, 6, or 8.

[0371] Examples of transactions available to employers 16 are: groupeligibility, group enrollment, enrollment changes, formulary lookup,e-commerce integration, access from health plan web site or directaccess via URL, personalized content integration, both context-specificand on demand, e-commerce integration: human resource, business (e.g.,office supplies) and health care-related product awareness and buyingcapabilities.

[0372] Again, as a further example, the following are specific recordsand fields for health care transactions between employers 16 andinsurers 11 that utilize normalized data:

[0373] Record: Open Enrollment

[0374] Fields:

[0375] Health Insurance

[0376] Employer Group Number

[0377] Last Name

[0378] First Name

[0379] Middle Name

[0380] Employee Address 1

[0381] Address 2

[0382] City

[0383] State

[0384] zip

[0385] Home Phone

[0386] Work Phone

[0387] Primary Language

[0388] Birth date

[0389] Gender

[0390] Social Security Number

[0391] Primary Care Physician

[0392] Established Patient

[0393] Dependent Last Name

[0394] First Name

[0395] Middle Initial

[0396] Birth date

[0397] Gender

[0398] Relationship Social

[0399] Security Number

[0400] Primary Care Physician

[0401] Established Patient

[0402] Effective Date

[0403] Hire/Rehire Date

[0404] Other Health Care Policy

[0405] Name and Address of Insurer

[0406] Effective date of other coverage

[0407] Policy Holder's Last Name

[0408] First Name

[0409] Middle Name

[0410] Policy/Group Number

[0411] Covered by Medicare

[0412] Medicare Number(s)

[0413] Health insurance within the last 18 months

[0414] If yes, type of coverage: group, individual, COBRA,Medicare/Champus, Conversion or Other

[0415] Reason coverage was terminated

[0416] Read and Agree to Authorization Statement

[0417] Record: Enrollment-Changes

[0418] Fields:

[0419] Health Insurance

[0420] Employer Group Number

[0421] Last Name

[0422] First Name

[0423] Middle Name

[0424] Employee Address 1

[0425] Address 2

[0426] City

[0427] State

[0428] zip

[0429] Home Phone

[0430] Work Phone

[0431] Primary Language

[0432] Birth date

[0433] Gender

[0434] Social Security Number

[0435] Primary Care Physician

[0436] Established Patient

[0437] Term Member

[0438] Dependent Last Name

[0439] First Name

[0440] Middle Initial

[0441] Birth date

[0442] Gender

[0443] Relationship

[0444] Social Security Number

[0445] Primary Care Physician

[0446] Term Dependent

[0447] Hire/Rehire Date

[0448] Effective Date Change

[0449] Reason

[0450] Name

[0451] Enrollment Type

[0452] Remarks

[0453] Examples of transactions available to patients 18 are:identification card requests, address changes, provider directoryinquiries, and personalized health information based on the member'sinterest profile, as well as diagnosis information from health planadministrative and clinical information, relevant articles and patienteducation materials, communications from health care providers andhealth care plans, lab and radiology results to patients online,scheduled appointments with a health care provider, referral status,prescription refills, education materials, personal health records so itcan be maintained in his or her comprehensive health history online forphysician reference, view eligibility/benefit information, view claiminformation, view referral and authorization information, providerlookup, personal health record, family history, medication profile,formulary lookup, and communications between member and provider.

[0454] The architecture of the data processing system 10 is shown inFIG. 2. Each of the database sets 4, 6, 8 is operatively connected todata connectivity sub-system 20. The data connectivity sub-system 20 isconfigured to receive the different types of connections used betweenthe various computer systems which store the database sets 4, 6, 8. Itis appreciated that, in other embodiments, a separate data processingsystem 10 may be provided at the site of each of the database sets 4, 6,8 such that each data processing system 10 is dedicated to manage andnormalize the data, as discussed further herein, as well as manageserver-to-server communications for a single database set.

[0455] The data extraction sub-system 28 is also depicted in FIG. 2.Sub-system 28 manages the integration of the often plurality ofdatabases. The data extraction sub-system 28, as further discussed inreference to FIG. 3 also includes logic to manage data access from theseveral databases of database sets 4, 6, 8. An enterprise master personindex (“EMPI”) 30 is operatively coupled to data extraction sub-system28. The EMPI 30 presents a cross-database view of all the insuredswithin system 2. It also manages the proper identification of providers14, employers 16, connected patients 18, as well as other entitieshaving unique identities on an as-needed basis. An indices database 32is supported by EMPI 30. Specifically, the indices database 32 storesindices which serve as a basis for relating the identification data toeach other. The indices database 32 is typically built upon andmaintained by the EMPI 30.

[0456] The business object sub-system 34 contains the logic rules thatdrives the normalization of data and use-of same between insurers 11 andparticipants 13. To provide such capabilities, a variety of processesmay be supported in any particular situation. Illustratively, suchprocesses may include, but are not limited to, rules-based evaluation ofentered data for referral authorizations and admissionpre-certifications; proxy or actual adjudication of claims submitted byproviders, with concomitant delivery of finds to insurers 11 andbenefits explanations to patients 18; sorted lists of providers 14,employers 16, and patients 18; and graphical displays of laboratoryresults and integrated claims-driven health records for patients 18.

[0457] The content/e-commerce sub-system 36 adds third partycapabilities to the data processing system 10. The content portion ofsub-system 36 provides management and integration of third partyaffiliated content, such as articles about diseases, bulletins, notices,notes, and other medically-related references. The e-commerce portion ofsub-system 36 integrates e-commerce capabilities, includingbusiness-to-business or business-to-consumer purchasing through shoppingcart-type databases with affiliated product and service vendors.

[0458] The personalization sub-system 38 integrates information from theprevious sub-systems 20, 28, 34, 36 to provide a personalized view ofdata in system 2. Specifically, when any of the participants 13 login tosystem 2 and access data or other information from database sets 4, 6,or 8, or even the content/e-commerce sub-system 36, pertinentinformation derived from the type of content viewed, as well as theproducts purchased or searched, is maintained in a user profile database40. During subsequent logins, therefore, the information a particularuser views can be arranged and accessed in a more familiar, relevant,and useful manner, individual to that participant.

[0459] The presentation sub-system 42 manages the normalized data andinformation into a presentable format for participants 13. For example,the world-wide-web, being a popular destination for users of theinternet, accepts output in HTML format, and is accessible by aconventional internet browser. It is appreciated, however, that suchdata may be presented in virtually any form to accommodate differentaccess devices (for example, WAP for mobile devices).

[0460] A security sub-system 44 is shown in FIG. 2 integrated with theother sub-systems 20, 28, 34, 36, 38, 42. Security sub-system 44maintains data security in several ways. First, one embodimentcontemplates that the insurers' 11 data is maintained on its own on-sitedatabase, and is controlled by the insurers 11. Second, the insurers' 11data is encrypted when it is routed from the insurers' 11 database tothe connectivity sub-system 20 and, ultimately, the participants 13 whena request 22 is made. Third, the participants' 13 browser includesencryption to view or send data over the internet 12. Finally, internalsecurity is built into the data processing system 10 to only allow userswith need-to-know access to particular data, such as claims and referralinformation. For example, providers 14 may have access only to claimsand referral information of their insurers, but not individual claimsummaries of their patients. Similarly, the employers 16 may have accessto only their employees' claims information, but not some personalinformation.

[0461] An example of an encryption method is the 128 bit Secure SocketsLayer (SSL) with a key certified by VeriSign, Inc. Such SSL encryptionmeans that data traveling through the internet and to participants' 13browser cannot be interpreted by anyone between those two locations.Encryption is also useful because of the storage of user passwords.There is no place that a user's password is saved or used by the systemas traditional cleartext. From one of the participants' 13 browserthrough internet 12 and to one of the insurers' 11 computer or server,the password is protected by SSL. Once the password reaches the finaldestined server, a cryptographic algorithm converts the password to aprotected format. No one, therefore, who has privileged access to theserver or any of the back-end applications can get any user passwords.

[0462] In addition, encryption is useful along the operative connectionto an insurer's 11 database sets 4, 6, or 8 to the data processingsystem 10. It is contemplated, however, that insurers' 11 computers orservers (database sets 4, 6, or 8) may not need such encryption alongthis operative connection, if the connection is a true point-to-pointconnection. Also, this encryption can be implemented through hardware orsoftware, a virtual private network (VPN), or through the use ofencryption protocols in a database, for example.

[0463] There are several modes with which data can be restricted, evenwithin and among the insurers 11 and participants 13 of system 2. Forexample, security sub-system 44 may restrict the actual data that aparticipant 13 may request or view from any of insurers 11. A healthcare organization, thus, may only view data that they have provided. Forexample, doctors may only view claim data for their own patients.Alternatively, security sub-system 44 may restrict access toparticipants 13 to allow access to only particular fields on aparticular screen of any particular database. For example, if a screenlisted dollar amounts for claims, employers may wish to restrict who isable to view those dollar amounts. Other users, therefore, like patients18, might be able to see the rest of the claims, but not the dollaramounts. Still, further, security sub-system 44 may restrict whichscreens will be accessible to which users. This level of securitydefines which functionality is available to the user. For example, apatient 18 in system 2 may not be able to view the claim submittalscreen submitted by provider 14 at all, but may view a diagnosisinformation or health plan administrative screen. Customizable securitybased on the interests of the user may be included as well. Thissecurity method allows either the insurers 11 or participants 13 to setthe parameters of security for the examples described above. It isfurther contemplated that this tool may be an internet-based tool thatcould add logins to the system, as well as specify values and screensthat a particular user has access to. It is still further contemplatedthat a portion or all of the security measures can be employedthroughout data processing system 12.

[0464] An audit sub-system 46, like security sub-system, 44, shown inFIG. 2, is also integrated with the other sub-systems 20, 28, 34, 36,38, 42. Audit sub-system 46 tracks the operation of all sub-systems. Theinformation generated from audit sub-system 46 allows an administratorto monitor the operation of system 2 for problems and marketing trends.

[0465] A diagrammatic view of the data extraction and business objectsub-systems 28, 34, respectively, is shown in FIG. 3. As previouslydiscussed, the numerous databases represented by database sets 4, 6, 8contain data in a variety of formats. Before the data is transferred toone of the participants 13, however, it is first formatted to a newformat that is readable by any of the computers of participants 13, likeHTML format, for example. The data is, therefore, “extracted” from thedatabase sets, either 4, 6, or 8, and then “normalized” to be read bythe computers of participants 13. The extracted data is indicated byreference numeral 48.

[0466] Extracted data 48 from either database sets 4, 6, or 8 isuploaded to a staging database 50 which is typically a portion of dataextraction sub-system 28. Rules engine 52 serves a dual purpose ofdefining the rules that control the normalization of the data, as wellas how the data, once normalized, is used. During the normalizationprocess at 54, rules engine 52 homogenizes the data by determining whatthe data means, then inserting the data into the proper field asnormalized data. Rules engine 52 also remodels the data, if necessary,to a structure or appearance predefined by the normalized format. As asimple example, in a referrals database that may hypothetically exist ondatabase set 6, it may include the entry “New Jersey” in the statelocation field. If that field is requested by a participant 13, therules engine 52 will cause that field to be extracted, then determinewhether the meaning of this field corresponds to the meaning of thenormalized state location field, and, if so, then convert the field tothe normalized state location field at 58. Furthermore, if the rulesengine 52 has predetermined that the normalized state location fieldshould exist as only a two-character acronym, then the phrase “NewJersey” will be remodeled to the acronym “NJ.” This is contrasted withtraditional transliterating programs that would merely match the statelocation field of the referrals database with any field in anotherdatabase titled “state location field” and then transfer the data. Sucha program cannot determine the meanings of the state location fields,and then determine if their meanings matched, as well as not remodel thedata to the appropriate appearance. For example, a field for laboratoryenzymes might be expressed in Celcius in one database and in Fahrenheitin another database. Such data, as well as countless other data, aretypically contextualized by the system they exist in. Transliteratingprograms do not compensate for such context among data. In the presentdisclosure, part of the normalization is determining the meaning of thedata and locating it in a field of the same definition, but in a singleformat.

[0467] Rules engine 52 also determines whether the data is bad orinvalid. Any bad or invalid data that is discovered during thenormalization process at 54 is transferred to an invalid data database56. Invalid data is placed in database 56 for review and appropriatecorrective action and, if appropriate, reintroduced and normalized.

[0468] In addition, the rules engine 52 incorporates security 44 todetermine whether the requestor has authorization to view the data thatis being requested, as previously discussed. For example, if employer 16requests claims data that illustratively exists on database set 8, therules engine 52, in conjunction with the security 44, determines whetheremployer 16 has authorization to view the data subject of that request.If not, rules engine 52 would deny fulfillment of the request.

[0469] Once the data is converted and remodeled into the normalizedformat, rules engine 52 determines how the normalized data can be used.For example, if a request 22 is made from providers 14 to one of theinsurers 11 to authorize a chest X-ray for one of the patients 18, aproper response 24 may reference data from various eligibility, claims,benefits, and personal data databases which rules engine 52 firstextracts and normalizes. Once the data is normalized, rules engine 52undertakes the process of responding to request 22. Rules engine 52bases response 24 on predetermined rules established by the particularinsurer 11 to determine whether a chest x-ray is an approved procedurein response to the request. It is contemplated that each insurer 11, oreven each database set 4, 6, 8 can be subject to its own unique set ofrules to govern any particular response 24.

[0470] An audit database 62, illustrated in FIG. 3, manages andmaintains tracking information during the conversion process at 58. Alldata requests, responses, and e-commerce submissions can be monitoredand recorded. This audit trail information is maintained in auditdatabase 62 to enhance performance and security characteristics. It iscontemplated that audit database 62 can be integrated with auditsub-system 46, as shown in FIG. 2, or database 62 can be a stand-alonesystem working independently or in addition to sub-system 46.

[0471] In one embodiment of the disclosure, it is contemplated thatsystem 2 will not only exchange information related to insurance andpayment issues, but also provide active management of patient care. Forexample, as shown in FIG. 4, a portion of system 2 depicts the processfor medical tests to be ordered, approved, and results submitted. Forexample, a health care provider 14, via the internet 12, places an orderfor a medical test. The order is transmitted through data processingsystem 10. The order is further transmitted at 72 to a laboratory 70,the order will disclose particular information that will be needed wheneither the specimen or the patient arrives. If a specimen is collectedby provider 14, the order will identify the laboratory 70, and provideinformation to provider 14 so that the specimen may be markedaccordingly before being sent to laboratory 70. Once laboratory 70receives the order and the specimen, laboratory 70 can eithercommunicate the status or results back through data processing system 10to both the provider 14 and the appropriate insurer 13′, as indicated byreference numerals 74, 76, respectfully.

[0472] Although the system has been described with reference toparticular means, materials and embodiments, from the foregoingdescription, one skilled in the art can easily ascertain the essentialcharacteristics of the illustrative system and various changes andmodifications may be made to adapt the various uses and characteristicswithout departing from the spirit and scope of the present invention asdescribed by the claims which follow.

What is claimed is:
 1. Apparatus for communicating health care data froma sender to a receiver comprising: a first computer system having healthcare data stored therein; a second computer system in operablecommunication with, and configured to extract the health care data fromthe first computer system; and a rules engine to normalize the extractedhealth care data to a predefined format, said rules engine defining aplurality of health care data fields in the predefined format and aplurality of relationships between fields of normalized data. 2.Apparatus of claim 1, further comprising a third computer system, inoperable communication with, and configured to receive the normalizeddata from, the second computer system.
 3. The system of claim 1, whereinthe first computer is a plurality of computers each having portions ofthe health care data stored thereon.
 4. The system of claim 2, whereinthe rules engine determines whether the third computer is authorized toreceive the health care data.
 5. The system of claim 1, wherein thenormalized data exchanged between the sender and receiver is chosen froma group comprising eligibility/benefit display, member roster, claimsubmission, provider lookup, formulary lookup, diagnosis code lookup,procedure code lookup, access health plan information online,communicate with a health plan on-line, communicate with patientson-line, patient-centric view of data across several health plans, ordergeneration and tracking, results review and release, result printing,prescription writing, medication profile for each patient, access topatient's personal health record based on patient approval, personalizedmedical and health care content integration, both context-specific andon demand, e-commerce integration: office, medical and health-relatedproduct awareness and buying capabilities, email, practice managementsystem subscription, support disease management, and physiciancredentialing subscription, wherein the receiver is a health careprovider.
 6. The system of claim 1, wherein the normalized dataexchanged between the sender and receiver is chosen from a groupcomprising group eligibility, group enrollment, enrollment changes,formulary lookup, e-commerce integration, access from health plan website or direct access via URL, personalized content integration, bothcontext-specific and on demand, e-commerce integration and healthcare-related product awareness and buying capabilities, wherein thereceiver is an employer.
 7. The system of claim 1, wherein thenormalized data exchanged between the sender and receiver is chosen froma group comprising identification card requests, address changes,provider directory inquiries, personalized health information based onan interest profile, diagnosis information, relevant articles andpatient education materials, communications from health care providersand health care plans, lab and radiology results, scheduled appointmentswith a health care provider, prescription refills, personal healthrecords, eligibility/benefit information, claim information, referraland authorization information and status, provider lookup, familyhistory, medication profile and formulary lookup, wherein the receiveris a patient.
 8. A method for communicating health care data from onecomputer system to another, comprising the steps of: storing health caredata in a first computer system; extracting health care data from thefirst computer system and communicating the extracted data to a secondcomputer system; normalizing the extracted data to a predefined formatin accordance with a rules engine that defines a plurality of healthcare data fields in the predefined format and a plurality ofrelationships between fields of normalized data; and communicating thenormalized data to a third computer system.
 9. The method of claim 8,wherein said first computer system comprises a plurality of computers,and wherein said storing step includes storing health care data in morethan one of said computers.
 10. A method of claim 8, wherein said thirdcomputer system comprises a plurality of computers.
 11. The method ofclaim 8, wherein the health care data exists across a plurality ofdatabases, each of the plurality of databases being in operablecommunication with the second computer system.
 12. A system ofexchanging health care data between a sender and a receiver, the systemcomprising: a sender computer upon which health care data is stored; anintermediary computer in operable communication with the sendercomputer; wherein the intermediary computer is configured to extract thehealth care data; a rules engine configured to receive the extracteddata and normalize same to a predefined format, said rules enginedefines each field of the extracted data and converts each field to acorresponding field in the predefined format, creating normalized data,said rules engine also defines how the normalized data should relate toeach other pursuant to predetermined instructions; and a receivercomputer in operable communication with the intermediary computer andconfigured to receive the normalized data.
 13. The system of claim 12,wherein sender computer is a plurality of computers each having portionsof the health care data stored thereon.
 14. The system of claim 12,wherein the rules engine determines whether the receiver computer isauthorized to receive the health care data.
 15. The system of claim 12,wherein the normalized data exchanged between the sender and receiver ischosen from a group comprising eligibility/benefit display, memberroster, claim submission, provider-lookup, formulary lookup, diagnosiscode lookup, procedure code lookup, access health plan informationonline, communicate with a health plan on-line, communicate withpatients on-line, patient-centric view of data across several healthplans, order generation and tracking, results review and release, resultprinting, prescription writing, medication profile for each patient,access to patient's personal health record based on patient approval,personalized medical and health care content integration, bothcontext-specific and on demand, e-commerce integration: office, medicaland health-related product awareness and buying capabilities, email,practice management system subscription, support disease management, andphysician credentialing subscription, wherein the receiver is a healthcare provider.
 16. The system of claim 12, wherein the normalized dataexchanged between the sender and receiver is chosen from a groupcomprising group eligibility, group enrollment, enrollment changes,formulary lookup, e-commerce integration, access from health plan website or direct access via URL, personalized content integration, bothcontext-specific and on demand, e-commerce integration and healthcare-related product awareness and buying capabilities, wherein thereceiver is an employer.
 17. The system of claim 12, wherein thenormalized data exchanged between the sender and receiver is chosen froma group comprising identification card requests, address changes,provider directory inquiries, personalized health information based onan interest profile, diagnosis information, relevant articles andpatient education materials, communications from health care providersand health care plans, lab and radiology results, scheduled appointmentswith a health care provider, prescription refills, personal healthrecords, eligibility benefit information, claim information, referraland authorization information and status, provider lookup, familyhistory, medication profile and formulary lookup, wherein the receiveris a patient.
 18. A system of normalizing health care data for transferbetween an insurer and a participant, the system comprising: an insurersystem configured to maintain at least one database comprising thehealth care data; an intermediary system operatively connected to theinsurer system and to the database; wherein the intermediary system isconfigured to extract the health care data from the database of theinsurer system, and store the health care data in a staging database asextracted data; a rules engine configured to receive the extracted dataand normalize same to a predefined format, said rules engine defineseach field of the extracted data and converts each field to acorresponding field in the predefined format, creating normalized data,said rules engine also defines how the normalized data should relate toeach other pursuant to predetermined instructions; and a participantsystem in operable communication with the intermediary system; whereinthe participant system is configured to receive the normalized datasubject to the rules engine.
 19. The system of claim 18, wherein the atleast one database is a plurality of databases, wherein the intermediarysystem is operatively connected to the plurality of databases.
 20. Thesystem of claim 18, wherein the participant system transmits a requestthat is sent to the intermediary system that determines which healthcare data is to be extracted and normalized in order to respond to therequest.
 21. The system of claim 20, wherein the participant systemtransmits the request and the intermediary system transmits thenormalized data over the internet.
 22. The system of claim 18, whereinthe intermediary system comprises an error data system that removesextracted data identified as invalid when the extracted data isnormalized.
 23. The system of claim 22, wherein the extracted dataidentified as invalid is corrected and reintroduced and is normalized.24. The system of claim 18, wherein the intermediary system comprises anaudit database to track activity of the intermediary system.
 25. Thesystem of claim 20, wherein the rules engine defines the relationshipsamong the normalized data pursuant to predetermined instructions todetermine a response to the request.
 26. A system of health caremanagement of medical testing administration between an insurer, amedical laboratory and at least one health care participant, the systemcomprising: a participant computer at which a medical test request ismade pursuant to a first predefined format; an insurer processing systemthat is operatively coupled to the participant's computer, and throughwhich the medical request is transferred; wherein the processing systemis operatively coupled to a rules database to approve the medica testrequest pursuant to predetermined criteria; and a laboratory computeroperatively coupled to the processing system and receives the medicaltest request if approved by the rules engine; wherein results of amedical test are transmitted from the laboratory computer to theprocessing system where the results are transmitted to an insurercomputer operatively coupled to the laboratory computer and toparticipant's computer.
 27. The system of claim 26, wherein theprocessing system converts the results of the medical test to a secondpredefined format readable by a database stored on the insurer computer.28. The system of claim 26, wherein the at least one health careparticipant is chosen from a group comprising from a health careprovider, an employer, and a patient.
 29. The system of claim 26,wherein the medical test request and the results of the medical test istransmitted through the internet.